Allow preexisting wrapper and custom class names #16805
Conversation
Fix test so that it expect the input's wrapper to have a class of "awesomplete-wrapper"
| className: "awesomplete", | ||
| around: input | ||
| }); | ||
| this.container = $("." + this.containerClass, this.input.parentNode) || |
There was a problem hiding this comment.
If the point is allowing a custom element for this, why not accept an element instead of a class? Or a selector, at the very least? Also, how will an element be around input and still be a child of its parent? Unless I’m missing something, that seems impossible.
There was a problem hiding this comment.
Ehm, no not really...
#16718 is about having a structure where an element must remain a sibling of the input, like in many material-design implementations.
right now, if we have
<div class="some-wrapper-class">
<input id="search" class="awesomplete someOtherClass" />
<label for="search">Search for something</label>
</div>Awesomplete will wrap the input with a div, separating it from from the label:
<div class="some-wrapper-class">
<div class="awesomplete">
<input id="search" class="awesomplete someOtherClass" />
</div>
<label for="search">Search for something</label>
</div>What's needed to resolve #16718 is for new Awesomeplete('.awsomplete', {containerClass: 'some-wrapper-class'} to not wrap the input - because it is already wrapped by some-wrapper-class - leaving us with the original structure, so that the input and the label remain siblings.
This, inherently, also allows for custom elements, as it just looks at the existing html to see if it can be left as is, or needs modifying, based on a class name. new Awesomplete should just leave the following as is, allowing for the wrapper to be an element that isn't a div:
<label class="awesomplete">
<input id="search" class="awesomplete someOtherClass" />
Search for something
</label>
|
Hello there! Thanks for contributing! |
Revert css changes; Update docs
|
Done |
|
This conflicts, at least in general purpose, with #16787, which sparked a discussion on the relation of Awesomplete to Bliss. The web of interconnected issues here likely means this PR (and that one) need to wait a bit before some of the underlying issues are made concrete. |
|
Any news? |
This PR adds two, somewhat related features:
is-visually-hidden, there is no reason to duplicate that style forvisually-hidden. Similarly, it is a likely use case that people using OOCSS style classes will want to assign classes to theul.awesomplete-wrapperby default).awesomplete-wrapperor the user-defined class.CSS, documentation and test updated to represent chnages.